@michaelklishin @mkuratczyk this is a simpler approach.

Another way to 'store' the cluster wide queue limit, instead of config, would perhaps be to store it as a global parameter?
i.e rabbitmqctl set_global_parameter cluster_limit '{"queue":"5"}'

Or, read the config at start and store the value in a db, and let it be overwritten by whatever node writes last?

Personally I don't think having a 'cluster setting' per node is that much of an issue, but am willing to change my mind quickly.

No, we should not use global parameters for things that are not dynamic in nature, and knowing the background on this, this is something that an absolute majority of installations will set in stone and rarely change, perhaps after a period of adaptation. Or not set in the first place.

OK, ill leave as is and add some tests.

@SimonUnge as for setting this cluster-wide setting on every node, since most cluster provisioning tools/options perform config generation one way or another, this won't be an issue. As long as the value is identical on all nodes anyway, which we can assume to be the case most of the time and/or eventually after a redeployment.

yes, I agree. Its the easiest and most straightforward approach to setting it.

Thanks Simon. The limit is enforced in the wrong place however - it's only applicable to AMQP 0.9.1 and "non-native" protocols, so that'd be just STOMP in 4.0 or perhaps not even that. I can easily declare more queues than the limit I set by:

• importing definitions
• starting MQTT subscriptions
• using stream-perf-test
  and probably a few other ways

I think these checks should be moved to rabbit_queue_type:declare

@mkuratczyk ah right you are, I'll move it (I basically just placed it where the vhost queue limit is). I'll move it to a better place.

I will not move the vhost limit in this PR to keep it clean, but can create an issue for it.

@michaelklishin noticed I pointed this one to v3.13.x... Should I switch to main?

You need to create a new branch off of main, cherry-pick the commit(s) there and push it, then submit a PR against main.

@michaelklishin Done. Also squashed this commit.

Will rebase on #11222 once merged, to combine the logic a bit.